我們用 SMART——Specific(具體)、Measurable(可衡量)、Achievable(可達成)、Relevant(具關聯)、Time-bound(有時限)——把每個故事拆成五天,作為每次動手造輪子前的五個檢查問題。
本篇是回顧總結的「治理」篇:當自研真的成為正確答案時,動手之前要先承諾什麼?
本篇定位:避免系列落入「永遠不要自研」的簡化結論,建立合理自研的門檻。
那套曾經被要求包成 AT Command 的命令協定,最後並沒有被丟掉。它以「以後可能用得到」回到規劃會議,被要求列出具名使用者;列不出來,於是掛上觸發條件、進了待辦清單。當時我以為那只是一個客氣的拒絕。
現在把觸發條件攤開來看,它其實是一份預先寫好的許可證。上面寫著兩種情況:如果這顆晶片上的工作日後要分給第二顆處理器執行,應用端與韌體之間就真的隔出了一條實體通道,跨處理器的命令與回應需要一套講清楚的格式;或者,如果有外部客戶要把這套設備整合進他們自己的系統,那套命令就成了跨組織的契約介面,得有版本、有錯誤碼、有相容性承諾。這兩種情況只要成立一種,同一份提案就從「多餘的翻譯」變成「正當的落點」。技術一個字都沒有改,改變的是它要跨越的邊界,以及提得出來的證據。
所以接下來要處理的是相反的一半:當觸發條件真的成立,該怎麼把這顆輪子造得名正言順。
重看五個故事,有一件容易被忽略的事:每一台破輪子的第一版,其實都做出來了,而且都能動。寫得出第一版,從來就不是自研的門檻——對一個手感好的工程師,第一版反而是整條生命週期裡最愉快、最便宜的部分。
真正的門檻在第一版之後:誰替它補胎,誰替它換軸,誰替它寫說明書,誰在原作者離開之後還看得懂它,誰有權在它該退役的時候把它拆掉。所以判斷要分成兩組問題。第一組問「值不值得造」:缺口是否具體且無法接受、法規或資安要求是否真的沒有妥協空間、授權模式與供應風險是否不可承受、這項能力是否會形成長期競爭力。第二組問「養不養得起」:團隊是否具備維護、測試與演進的能力,是否已有替代、回退與淘汰策略,以及最現實的一項——這件事花誰的預算、佔誰的人力。
第一組答得漂亮、第二組答不出來,是最危險的組合,因為它聽起來很像一個正確的技術決定。這種時候不必硬撐,有一條具體的出路:往上退回官方擴充或薄型轉接那幾級,先把眼前的需求用侵入較淺的方式撐住,同時把那個缺口原樣寫成對上游的功能請求,或寫進下一次採購與合約的條件裡。這樣做有兩個好處——今天的成本立刻止血,而缺口仍然留在別人的待辦清單上,有機會被原本就該補它的人補上。
門檻要能執行,就得落成文件。動手之前,替這顆輪子簽一份維護承諾,內容至少包含這幾項:
這疊文件看起來像官僚成本,實際上是所有權狀。簽不下去,就誠實地退回上一級,這不丟臉,這叫止損。簽得下去,這顆輪子就值得造,而且造的人從第一天起就可以抬頭挺胸:往後每一個「為什麼不用現成的」的質疑,文件裡都已經有答案。
真正值得造的輪子,不只要有人願意做第一版,還要有人願意替它補胎、換軸、寫說明書,最後也知道怎麼把它拆掉。
一路複盤下來,我原本以為要對付的是「太快動手」,最後發現真正的反派另有其人:沒有名字的責任。責任沒有名字,缺口就永遠是別人的問題,維護就永遠是明年的問題,退場就永遠是還沒發生的問題;五台破輪子最後留下的爛攤子,全都掛在這個空白的署名欄上。三樣工具做的其實是同一件事——決策梯把每一級的責任照順序排好,盤點表在動手之前把它們攤上桌面,維護承諾則要求有人在下面簽名。
那麼,簽完名之後呢?從那顆按不動的按鈕走到這份承諾,再往前還接著那個把工作當考卷寫的實習生。兩個三十天,到底把我從哪裡帶到了哪裡?